Reviewing files that changed from the base of the PR and between 39cd6af and f95836f.

• src/cpu/o3/fetch.cc
• src/cpu/o3/fetch.hh
• src/cpu/o3/fetch.md
• src/cpu/pred/BranchPredictor.py
• src/cpu/pred/btb/decoupled_bpred.cc
• src/cpu/pred/btb/decoupled_bpred.hh
• src/cpu/pred/btb/decoupled_bpred_stats.cc
• src/cpu/pred/btb/fetch_target_queue.cc
• src/cpu/pred/btb/fetch_target_queue.hh

• GitHub Check: Quick Build, Unit Tests & Smoke Test
• GitHub Check: perf_test / XS-GEM5 - Run performance test (spec06-0.3c)

src/cpu/o3/fetch.cc (1)

2071-2091: LGTM - Clean refactoring of the fetch loop termination condition.

The replacement of the inline condition with shouldStopFetchThisCycle(predictedBranch) properly centralizes the fetch stopping logic. The method in fetch.hh correctly handles:

1. waitForVsetvl gating
2. Decoupled frontend usedUpFetchTargets check
3. predictedBranch for traditional frontends

This sets a good foundation for future 2Fetch extensions.

src/cpu/pred/BranchPredictor.py (1)

1184-1187: LGTM - New 2Fetch configuration parameters are well-defined.

The new parameters follow gem5 conventions:

• Features disabled by default (False) ensures backward compatibility
• maxFetchBytesPerCycle=64 is a sensible default matching typical fetch buffer sizes
• The static analysis warnings about Param are false positives since it's imported via the star import from m5.params at line 29

src/cpu/o3/fetch.hh (1)

517-531: LGTM - Well-documented centralized fetch stop decision.

The shouldStopFetchThisCycle() method cleanly encapsulates the per-cycle fetch termination logic with:

• Clear documentation explaining the three cases
• Proper priority ordering (waitForVsetvl → decoupled frontend → predictedBranch)
• Inline implementation appropriate for this lightweight decision function

This consolidation improves maintainability and prepares the codebase for 2Fetch extensions.

src/cpu/o3/fetch.md (2)

344-353: Documentation accurately reflects the code changes.

The updated documentation correctly shows:

• The new shouldStopFetchThisCycle(bool predictedBranch) signature
• The three-way logic (waitForVsetvl → decoupled frontend → predictedBranch)
• Consistent with the implementation in fetch.hh

This keeps the documentation in sync with the refactored code.

---

584-586: Code example updated to match implementation.

The fetch loop condition example now correctly uses !shouldStopFetchThisCycle(predictedBranch), maintaining consistency between documentation and actual code.

src/cpu/pred/btb/fetch_target_queue.hh (1)

160-181: Well-designed 2Fetch lookahead API.

The new methods provide a clean interface for 2Fetch traversal:

• hasNext() / peekNext() / advance() follow a standard lookahead pattern
• Returning const FtqEntry& from peekNext() prevents unintended modifications
• peekNext() properly asserts the precondition via assert(hasNext()), ensuring safe use

src/cpu/pred/btb/decoupled_bpred_stats.cc (1)

508-514: LGTM! Statistics for 2Fetch feature are well-structured.

The new statistics cover all decision paths in the 2Fetch logic: attempts, successes, and specific rejection reasons. This provides good observability for tuning and debugging the feature.

src/cpu/pred/btb/fetch_target_queue.cc (1)

301-319: LGTM! advance() correctly updates supply state for 2Fetch.

The method properly updates supplyFetchTargetState to point to the current demand target (which has already been incremented by finishCurrentFetchTarget()). The fallback to invalidate supply state when the entry doesn't exist is appropriate.

src/cpu/pred/btb/decoupled_bpred.cc (2)

1401-1446: LGTM! canExtendToNextFTQ has well-structured validation.

The method correctly validates all preconditions for 2Fetch extension:

1. First block must end with a taken branch (to jump within the fetch buffer)
2. Next FTQ entry must be available
3. Current PC must match next FTQ's start (ensuring continuity)
4. Total span must fit within maxFetchBytesPerCycle

The early exit checks are ordered efficiently and each rejection path records a specific statistic for observability.

---

1456-1477: LGTM! extendToNextFTQ correctly sets up for processing the second FTQ entry.

The method properly:

1. Advances to the next FTQ entry via fetchTargetQueue.advance()
2. Resets the instruction counter for the new FTQ entry
3. Updates the PC to the start of the new FTQ entry
4. Records the successful 2Fetch metric

src/cpu/pred/btb/decoupled_bpred.hh (2)

383-389: LGTM! Statistics declarations are well-documented.

The statistics cover all decision paths in the 2Fetch logic with clear documentation comments explaining each counter's purpose.

---

1029-1041: LGTM! Method declarations are appropriate.

The method signatures correctly use const references where modification isn't needed and non-const reference for the PC that gets updated.